[Previous] [Next] [Index] [Thread]

RE: Re N$ SSL vs M$ PCT

"John Hemming CEO MarketNet"  <JohnHemming@mkn.co.uk> writes:
>
> I think I have not made my point clear.  I see no merit in combining
> a protocol for establishing a secure channel (SSL, PCT) and a
> protocol for authentication of transactions.  The sequence of octets
> that comprises a digitally signed cheque should stand alone as
> proof of authentication.  It may be passed through SSL or as a PGP
> encrypted message or even in the clear.

John,

I'm not sure I understand your objections.  Who is proposing that a
protocol for authenticating transactions be combined with eiher PCT
or SSL?  Are you perhaps objecting to the message authentication
(MAC) in PCT or SSL?  The intention of MACs is to prevent attackers
from injecting bogus messages, and in PCT the minimum MAC key length
is 64-bits; you're absolutely right that for certain important
messages -- e.g., payment orders like checks, or instructions to
stock brokers, etc -- that digital signatures would also be
necessary.  After all, MACs do not provide non-repudiation, an
important property of digial signatures.  People are looking at these
sort of applications; for example, the STT protocol
<URL:http://www.microsoft.com/windows/ie/stt.htm> that MS and Visa
announced is intended to address some of those issues in the area of
credit card transactions.

There are, however, an intermediate class of messages for which it
would be impractical to use digital signatures: for example,
implementing the telnet protocol on top of something like PCT, where
you wouldn't want an attacker to inject a "rm -fr *" (or "del *.*", I
guess) into your session; the overhead of digitally signing a
character-at-a-time protocol would be prohibitive.  For Web browsing,
it can be similarly important: suppose up-to-the-second stock quotes
are being served via the Web on a subscription basis.  Altering these
quotes could be an easy way to manipulate investors, but digitally
signing every quote is probably overkill.

> ...
>
> The level of processing of a digital instruction is higher than that of
> the channel and there does not seem to be anything to be gained from
> merging its protocol with the system.

> The point remains, however, that the client's strong RSA key is
> used for authentication in SSL anyway, not that I would use it.

That -is- a potential problem with key reuse if one is careless; I
wrote about this in a separate message.

-bsy